EuroSys'16 Best Paper
This paper supports the author's following work, graphene(-SGX).
Targeted Interfaces (APIs)
- System Calls
- Proc Filesystem
Method
- Measured the download and dependency data of packages in Ubuntu 15.04.
- Statically analyzed what syscalls will be invoked in a package and what path will be accessed by a binary (hardcoded string)
Measurement
- API Importance: A Metric for Individual APIs
- Weighted Completeness: A System-Wide Metric (combined with #downloads)
Questions Answered
- Which syscalls are more important than others?
- Which syscalls can be deprecated? (some are rarely used)
- Which syscalls should be supported for compatibility?
This paper analyzes the vulnerability space arising in Trusted Execution Environments (TEEs) when interfacing a trusted enclave application with untrusted, potentially malicious code. Considerable research and industry effort has gone into developing TEE runtime libraries with the purpose of transparently shielding enclave application code from an adversarial environment. However, our analysis reveals that shielding requirements are generally not well-understood in real-world TEE runtime implementations. We expose several sanitization vulnerabilities at the level of the Application Binary Interface (ABI) and the Application Programming Interface (API) that can lead to exploitable memory safety and side-channel vulnerabilities in the compiled enclave. Mitigation of these vulnerabilities is not as simple as ensuring that pointers are outside enclave memory. In fact, we demonstrate that state-of-the-art mitigation techniques such as Intel's edger8r, Microsoft's "deep copy marshalling", or even memory-safe languages like Rust fail to fully eliminate this attack surface. Our analysis reveals 35 enclave interface sanitization vulnerabilities in 8 major open-source shielding frameworks for Intel SGX, RISC-V, and Sancus TEEs. We practically exploit these vulnerabilities in several attack scenarios to leak secret keys from the enclave or enable remote code reuse. We have responsibly disclosed our findings, leading to 5 designated CVE records and numerous security patches in the vulnerable open-source projects, including the Intel SGX-SDK, Microsoft Open Enclave, Google Asylo, and the Rust compiler.
ABI vulnerabilities
Entry status flags sanitization
Entry stack pointer restore
Exit register leakage
API vulnerabilities
Missing pointer range check
Null-terminated string handling
Integer overflow in range check
Incorrect pointer range check
Double fetch untrusted pointer
Ocall return value not checked
Uninitialized padding leakage
Targets
SGX-SDK
OpenEnclave
Graphene
SGX-LKL
Rust-EDP
Asylo
Keystone
Sancus
that legacy applications may also make implicit assumptions on the validity of argv and envp pointers, which are not the result of system calls.
Filesystem + Formal Method + SGX
New trusted computing primitives such as Intel SGX have shown the feasibility of running user-level applications in enclaves on a commodity trusted processor without trusting a large OS. However, the OS can still compromise the integrity of an enclave by tampering with the system call return values. In fact, it has been shown that a subclass of these attacks, called Iago attacks, enables arbitrary logic execution in enclave programs. Existing enclave systems have very large TCB and they implement ad-hoc checks at the system call interface which are hard to verify for completeness. To this end, we present BesFS—the first filesystem interface which provably protects the enclave integrity against a completely malicious OS. We prove 167 lemmas and 2 key theorems in 4625 lines of Coq proof scripts, which directly proves the safety properties of the BesFS specification. BesFS comprises of 15 APIs with compositional safety and is expressive enough to support 31 real applications we test. BesFS integrates into existing SGX-enabled applications with minimal impact to TCB. BesFS can serve as a reference implementation for hand-coded API checks.
SGX to protect GPU then prevent cheating
Abstract
Online gaming, with a reported 152 billion US dollar market, is immensely popular today. One of the critical issues in multiplayer online games is cheating, in which a player uses an illegal methodology to create an advantage beyond honest game play. For example, wallhacks, the main focus of this work, animate enemy objects on a cheating player's screen, despite being actually hidden behind walls (or other occluding objects). Since such cheats discourage honest players and cause game companies to lose revenue, gaming companies deploy mitigation solutions alongside game applications on the player's machine. However, their solutions are fundamentally flawed since they are deployed on a machine where the attacker has absolute control.
ASPLOS 2020
Intel SGX is a hardware-based trusted execution environment (TEE), which enables an application to compute on confidential data in a secure enclave. SGX assumes a powerful threat model, in which only the CPU itself is trusted; anything else is untrusted, including the memory, firmware, system software, etc. An enclave interacts with its host application through an exposed, enclave-specific, (usually) bi-directional interface. This interface is the main attack surface of the enclave. The attacker can invoke the interface in any order and inputs. It is thus imperative to secure it through careful design and defensive programming.
In this work, we systematically analyze the attack models against the enclave untrusted interfaces and summarized them into the COIN attacks -- Concurrent, Order, Inputs, and Nested. Together, these four models allow the attacker to invoke the enclave interface in any order with arbitrary inputs, including from multiple threads. We then build an extensible framework to test an enclave in the presence of COIN attacks with instruction emulation and concolic execution. We evaluated ten popular open-source SGX projects using eight vulnerability detection policies that cover information leaks, control-flow hijackings, and memory vulnerabilities. We found 52 vulnerabilities. In one case, we discovered an information leak that could reliably dump the entire enclave memory by manipulating the inputs. Our evaluation highlights the necessity of extensively testing an enclave before its deployment.
Target
To find vulnerabilities of SGX applications in four models:
Concurrent calls: multithread, race condition, improper lock…
Order: assumes the calling sequence
Input manipulation: bad OCALL return val & ECALL arguments
Nested calls: calling OCALL that invokes ECALL, not implemented
Design & Method
The design of COIN:
Emulation: QEMU
Symbolic execution: Triton (backed by z3)
Policy-based vulnerability discovery
Results
COIN uses 8 policies to find the potential vulnerabilities:
Heap info leak
Stack info leak
Ineffectual condition
Use after free
Double free
Stack overflow
Heap overflow
Null pointer dereference
Review
Strength
Symbolic execution + emulation
Policies can be configurable
Real world problems
Weakness
nested call left unimplemented
May not be powerful enough to deal with complicate situations
Policies are mainly at relatively low-level
The presence of large numbers of security vulnerabilities in popular feature-rich commodity operating systems has inspired a long line of work on excluding these operating systems from the trusted computing base of applications, while retaining many of their benefits. Legacy applications continue to run on the untrusted operating system, while a small hyper visor or trusted hardware prevents the operating system from accessing the applications' memory. In this paper, we introduce controlled-channel attacks, a new type of side-channel attack that allows an untrusted operating system to extract large amounts of sensitive information from protected applications on systems like Overshadow, Ink Tag or Haven. We implement the attacks on Haven and Ink Tag and demonstrate their power by extracting complete text documents and outlines of JPEG images from widely deployed application libraries. Given these attacks, it is unclear if Over shadow's vision of protecting unmodified legacy applications from legacy operating systems running on off-the-shelf hardware is still tenable.
The key intuition is to exploit the fact that a regular applicationusually shows different patterns in control transfers or data accesses when the sensitive data it is processing are different.
- Induce Page Fault
- Recognize page access -> control/data flow
- Recover sensitive info
Mitigation
As control-flow hijacking defenses gain adoption, it is important to understand the remaining capabilities of adversaries via memory exploits. Non-control data exploits are used to mount information leakage attacks or privilege escalation attacks program memory. Compared to control-flow hijacking attacks, such non-control data exploits have limited expressiveness, however, the question is: what is the real expressive power of non-control data attacks? In this paper we show that such attacks are Turing-complete. We present a systematic technique called data-oriented programming (DOP) to construct expressive non-control data exploits for arbitrary x86 programs. In the experimental evaluation using 9 programs, we identified 7518 data-oriented x86 gadgets and 5052 gadget dispatchers, which are the building blocks for DOP. 8 out of 9 real-world programs have gadgets to simulate arbitrary computations and 2 of them are confirmed to be able to build Turing-complete attacks. We build 3 end-to-end attacks to bypass randomization defenses without leaking addresses, to run a network bot which takes commands from the attacker, and to alter the memory permissions. All the attacks work in the presence of ASLR and DEP, demonstrating how the expressiveness offered by DOP significantly empowers the attacker.
There are no function call gadgets in data-oriented programming, as it does not change the control data.
- Operate on data to achieve arbitrary computation
We introduce a new concept called brokered delegation. Brokered delegation allows users to flexibly delegate credentials and rights for a range of service providers to other users and third parties. We explore how brokered delegation can be implemented using novel trusted execution environments (TEEs). We introduce a system called DelegaTEE that enables users (Delegatees) to log into different online services using the credentials of other users (Owners). Credentials in DelegaTEE are never revealed to Delegatees and Owners can restrict access to their accounts using a range of rich, contextually dependent delegation policies.
DelegaTEE fundamentally shifts existing access control models for centralized online services. It does so by using TEEs to permit access delegation at the user's discretion. DelegaTEE thus effectively reduces mandatory access control (MAC) in this context to discretionary access control (DAC). The system demonstrates the significant potential for TEEs to create new forms of resource sharing around online services without the direct support from those services.
We present a full implementation of DelegaTEE using Intel SGX and demonstrate its use in four real-world applications: email access (SMTP/IMAP), restricted website access using a HTTPS proxy, e-banking/credit card, and a third-party payment system (PayPal).
- Account sharing: delegate the credentials to other users securely
- Centrally and P2P
Old version: Binary Compatibility For SGX Enclaves
Yet another middleware to support unmodified binary to run in SGX enclave. This is done through dynamically rewrite binary inside the encalve.
Enclaves, such as those enabled by Intel SGX, offer a hardware primitive for shielding user-level applications from the OS. While enclaves are a useful starting point, code running in the enclave requires additional checks whenever control or data is transferred to/from the untrusted OS. The enclave-OS interface on SGX, however, can be extremely large if we wish to run existing unmodified binaries inside enclaves. This paper presents Ratel, a dynamic binary translation engine running inside SGX enclaves on Linux. Ratel offers complete interposition, the ability to interpose on all executed instructions in the enclave and monitor all interactions with the OS. Instruction-level interposition offers a general foundation for implementing a large variety of inline security monitors in the future.
We take a principled approach in explaining why complete interposition on SGX is challenging. We draw attention to 5 design decisions in SGX that create fundamental trade-offs between performance and ensuring complete interposition, and we explain how to resolve them in the favor of complete interposition. To illustrate the utility of the Ratel framework, we present the first attempt to offer binary compatibility with existing software on SGX. We report that Ratel offers binary compatibility with over 200 programs we tested, including micro-benchmarks and real applications such as Linux shell utilities. Runtimes for two programming languages, namely Python and R, tested with standard benchmarks work out-of-the-box on Ratel without any specialized handling.
Abstract
There has been interest in mechanisms that enable the secure use of legacy code to implement trusted code in a Trusted Execution Environment (TEE), such as Intel SGX. However, because legacy code generally assumes the presence of an operating system, this naturally raises the spectre of Iago attacks on the legacy code. We observe that not all legacy code is vulnerable to Iago attacks and that legacy code must use return values from system calls in an unsafe way to have Iago vulnerabilities.
Based on this observation, we develop Emilia, which automatically detects Iago vulnerabilities in legacy applications by fuzzing applications using system call return values. We use Emilia to discover 51 Iago vulnerabilities in 17 applications, and find that Iago vulnerabilities are widespread and common. We conduct an in-depth analysis of the vulnerabilities we found and conclude that while common, the majority (82.4%) can be mitigated with simple, stateless checks in the system call forwarding layer, while the rest are best fixed by finding and patching them in the legacy code. Finally, we study and evaluate different trade-offs in the design of Emilia.
- Target: SGX Applications running inside a middleware
- Method: Fuzzing
- Tool:
strace(to intercept syscall return value)
Fuzzing Strategies
- Target selection (syscalls)
- Extract branch conditions depending on the return value from syscalls
- Random/valid/invalid return values
- Different return fields
Evaluation
to be continued
Graphene-SGX: A Practical Library OS for Unmodified Applications on SGX
LibOS in enclave + unmodified binary
Intel SGX hardware enables applications to protect themselves from potentially-malicious OSes or hypervisors. In cloud computing and other systems, many users and applications could benefit from SGX. Unfortunately, current applications will not work out-of-the-box on SGX. Although previous work has shown that a library OS can execute unmodified applications on SGX, a belief has developed that a library OS will be ruinous for performance and TCB size, making application code modification an implicit prerequisite to adopting SGX.
This paper demonstrates that these concerns are exaggerated, and that a fully-featured library OS can rapidly deploy unmodified applications on SGX with overheads comparable to applications modified to use “shim” layers. We present a port of Graphene to SGX, as well as a number of improvements to make the security benefits of SGX more usable, such as integrity support for dynamically-loaded libraries, and secure multi-process support. Graphene-SGX supports a wide range of unmodified applications, including Apache, GCC, and the R interpreter. The performance overheads of Graphene- SGX range from matching a Linux process to less than 2× in most single-process cases; these overheads are largely attributable to current SGX hardware or missed opportunities to optimize Graphene internals, and are not necessarily fundamental to leaving the application unmodified. Graphene-SGX is open-source and has been used concurrently by other groups for SGX research.
- Graphene-SGX assumes trusted binary, so it cannot protect enclave from malicious code/vulnerable code
- Graphene-SGX loads its enclave first, and let the enclave then load the so-called unmodified binary
- Interfaces are re-implemented in LibOS or export to the OS (Ocall)
- To improve performance, some Ocalls can be exitless. This is implemented through writing the arguments outside the enclave at a specific location (ocall stack) and the outside code can help execute with these args.
- Exploits BPU(Branch-prediction Unit)
- Train BPU to mispredict in a shadow program and observe side-channel
Intel has introduced a hardware-based trusted execution environment, Intel Software Guard Extensions (SGX), that provides a secure, isolated execution environment, or enclave, for a user program without trusting any underlying software (e.g., an operating system) or firmware. Researchers have demonstrated that SGX is vulnerable to a page-fault-based attack. However, the attack only reveals page-level memory accesses within an enclave.
In this paper, we explore a new, yet critical, sidechannel attack, branch shadowing, that reveals fine-grained control flows (branch granularity) in an enclave. The root cause of this attack is that SGX does not clear branch history when switching from enclave to non-enclave mode, leaving fine-grained traces for the outside world to observe, which gives rise to a branch-prediction side channel. However, exploiting this channel in practice is challenging because 1) measuring branch execution time is too noisy for distinguishing fine-grained control-flow changes and 2) pausing an enclave right after it has executed the code block we target requires sophisticated control. To overcome these challenges, we develop two novel exploitation techniques: 1) a last branch record (LBR)-based history-inferring technique and 2) an advanced programmable interrupt controller (APIC)-based technique to control the execution of an enclave in a fine-grained manner. An evaluation against RSA shows that our attack infers each private key bit with 99.8% accuracy. Finally, we thoroughly study the feasibility of hardware-based solutions (i.e., branch history flushing) and propose a software-based approach that mitigates the attack.
记录一下折腾这个笔记的过程
现在我采用的方案是 TiddlyWiki Server 的目录放在我的 Github Pages 主页中，然后每次commit之前重新生成一个 html 链接在主站上面。
插件
我使用了一些插件来支持markdown, LaTeX 等常用组件。
Cheat Sheet
List all under a tag:
<<list-links "[tag[SGX]]">>List tiddlers having two tags simultaneously:
<<list-links "[tag[SGX]tag[Paper]]">>
PartEmu
USENIX Security 2020
Source code unavailable
Traditional TrustZone OSes and Applications is not easy to fuzz because they cannot be instrumented or modified easily in the original hardware environment. So to emulate them for fuzzing purpose.
Targets
Emulate TrustZone OSes(TZOS) and Trusted Applications (TAs)
Abstract and reimplement a subset of hardware/software interfaces
Fuzz these components
TZOSes: QSEE, Huawei, OPTEE, Kinibi, TEEGRIS(Samsung) & TAs
Design & Method
Re-host the TZOS frimware
Choose the components to reuse/emulate carefully
Bootloader
Secure Monitor
TEE driver and TEE userspace
MMIO registers (easy to emulate)
Tools
TriforceAFL + QEMU
Manually written Interfaces
Results
Emulations works well. For upgraded TZOSes, only a few efforts are needed for compatibility.
TAs
Challenges
Identifying the fuzzed target
Result stability (migrate to hardware, reproducibility)
Randomness
| Class | Vulnerability Types | Crashes |
|---|---|---|
| Availability | Null-pointer dereferences | 9 |
| Insufficient shared memory crashes | 10 | |
| Other | 8 | |
| Confidentiality | Read from attacker-controlled pointer to shared memory | 8 |
| Read from attacker-controlled | 0 | |
| OOB buffer length to shared memory | ||
| Integrity | Write to secure memory using attacker-controlled pointer | 11 |
| Write to secure memory using | 2 | |
| attacker-controlled OOB buffer length |
Just like the previous paper, the main causes of the crashes can be attributed to:
Assumptions of Normal-World Call Sequence
Unvalidated Pointers from Normal World
Unvalidated Types
TZOSes
Normal-World Checks
Assumptions of Normal-World Call Sequence
Review
Strength
Solid work
Efforts taken to run TZOS and TA in emulation environment
Acceptable performance
Weakness
Low coverage
Crashes -X-> vulnerabilities
Intel Software Guard Extensions (SGX) offers strong confidentialityand integrity protection to software programs running in untrustedoperating systems. Unfortunately, SGX may be abused by attackersto shield suspicious payloads and conceal misbehaviors in SGXenclaves, which cannot be easily detected by existing defense solu-tions. There is no comprehensive study conducted to characterizemalicious enclaves. In this paper, we present the first systematicstudy that scrutinizes all possible interaction interfaces betweenenclaves and the outside (i.e., cache-memory hierarchy, host vir-tual memory, and enclave-mode transitions), and identifies sevenattack vectors. Moreover, we proposeSGX-Bouncer, a detectionframework that can detect these attacks by leveraging multifariousside-channel observations and SGX-specific features. We conductempirical evaluations with existing malicious SGX applications,which suggestsSGX-Bouncercan effectively detect various abnor-mal behaviors from malicious enclaves.
Middlewares
Container-like
- Graphene-SGX Paper Code
- SGX-LKL Paper Code
- Occlum Paper Code
- Scone Official Website Paper PDF Source Code Unavailable
- Ryoan Paper Code doesn't work
- RATEL
- CAT
Need updates - Civet [Paper|https://www.usenix.org/conference/usenixsecurity20/presentation/tsai] (graphene)
Language-specific
SDK/API/Runtimes
- Intel SGX Code
- Google Asylo Code
- Open Enclave Code
- Fortanix Rust EDP Code
- Teaclave SGX SDK (Rust-SGX) Paper PDF Code
- Panoply Code Inactive
Parallel
Attacks
Meta
Official Documents
Reviews
Attacks:
- A Tale of Two Worlds: Assessing the Vulnerability of Enclave Shielding Runtimes
- COIN Attacks: On Insecurity of Enclave Untrusted Interfaces in SGX
- Controlled-Channel Attacks: Deterministic SideChannels for Untrusted Operating Systems
- Emilia: Catching Iago in Legacy Code
- Inferring Fine-grained Control Flow Inside SGX Enclaves with Branch Shadowing
- Software Grand Exposure: SGX Cache Attacks Are Practical
Defenses:
- BlackMirror: Preventing Wallhacks in 3D Online FPS Games
- See through Walls: Detecting Malware in SGX Enclaves with SGX-Bouncer
Applications:
See also:
Intel SGX isolates the memory of security-critical applications from the untrusted OS. However, it has been speculated that SGX may be vulnerable to side-channel attacks through shared caches. We developed new cache attack techniques customized for SGX. Our attack differs from other SGX cache attacks in that it is easy to deploy and avoids known detection approaches. We demonstrate the effectiveness of our attack on two case studies: RSA decryption and genomic processing. While cache timing attacks against RSA and other cryptographic operations can be prevented by using appropriately hardened crypto libraries, the same cannot be easily done for other computations, such as genomic processing. Our second case study therefore shows that attacks on non-cryptographic but privacy sensitive operations are a serious threat. We analyze countermeasures and show that none of the known defenses eliminates the attack.
- L1 cache
- Prime + Probe
In Figure 2, the attacker will observe an increased access time for cache line 2. Since the attacker knows the code and access pattern of the victim, he knows that address X of the victim maps to cache line 2, and that the sensitive key-bit must be zero.
Generated List:
- A Study of Modern Linux API Usage and Compatibility: What to Support When You’re Supporting
- BesFS: A POSIX Filesystem for Enclaves with a Mechanized Safety Proof
- Data-Oriented Programming: On the Expressiveness of Non-Control Data Attacks
- GrapheneSGX
- PARTEMU: Enabling Dynamic Analysis of Real-World TrustZone Software Using Emulation